Mailkit upgrade #8746
Mailkit upgrade #8746
Conversation
|
The thing the compile check is failing on is not something I changed in this PR, I think? |
|
Try to rerun the build, or maybe check if there is a floating version somehow that would fail without any change. |
|
if it still doesn't build, I'll "recreate" the PR on step at a time. |
AndreaPiovanelli
force-pushed
the
mailkit_upgrade
branch
from
051c601
to
bb77e07
Compare
|
System.Net.Http is unfortunately a well-known troublemaker, although the relevant threads I found about it all state that it should stop causing problems with .NET 4.8 (or even 4.7.2). I've seen the same/similar errors before (some combination of Upgrade, Orchard.Workflows and Orchard.Email were involved), but managed to find a stable (at least it looked stable at the time) configuration. It looks like that MimeKit (or one of its dependencies) causes a conflict again, maybe it requires a more recent version of I'm working on this too, but in the meanwhile, if you isolate any specific change/version that causes the warning (error), please let me know. This might help: https://nickcraver.com/blog/2020/02/11/binding-redirects/#the-fix-if-youre-using-net-framework |
|
I managed to get view compilation pass by upgrading Also tested the upgrade to 4.1.0 on current 1.10.x and dev. I'll submit a PR targeting 1.10.x for that soon. |
|
Please merge the latest 1.10.x to fix the build error. |
# Conflicts: # src/Orchard.Web/Modules/Orchard.Email/packages.config
MatteoPiovanelli-Laser
force-pushed
the
mailkit_upgrade
branch
from
bb77e07
to
894c06f
Compare
|
rebased on 1.10.x |
Since upgrading to mailkit, we've been having a few issues.
Specifically, it looked like the client (i.e. Orchard, where Mailkit is) didn't wait for the smtp server to acknowledge reception of message data. Often, we would get this error on our SMTP servers:
We tried to upgrade the version of the NuGet package, but there were several issues with its dependencies (jstedfast/MailKit#1462, jstedfast/MimeKit#872, dotnet/sdk#31147) so we were only able to advance it to 3.4.2.
We then changed the code a bit, to explicitly disconnect from the STMP server and dispose of the smtpclient after sending each email. This seems to have improved things.
We couldn't replicate the error 100% of the time, but so far in our tests with this code it hasn't occurred yet.